Correcting IntentResult error in FDC3 2.0 and adding a very minor clarification to 2.1/next #1127
Conversation
…rification to 2.1/next
✅ Deploy Preview for fdc3 ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
…dmonitions as danger
|
Not sure if it changes the discussion, but this change in the .NET bindings is more significantly breaking on update. If I declare the interface member as Task<IIntentResult?> any desktop agents implementing this will fail to build on upgrade of the library (on a non semver major). With that said, we are publishing still as alpha versions and this can be a change when moving to publishing under Finos.Fdc3 |
|
@bingenito I understand your comment on this - it is a breaking change. It's one we already made in FDC3 2.1 (and without incrementing the major version number), as it wasn't what was intended in 2.0 (due to a mistake on my part). When we agreed to change this in 2.1 there was a feeling that this feature wasn't heavily used (yet) and hence the sooner we fix it the better. Based on your comment, I think that still holds (although less so for those already using the .NET types) - but we very much need to avoid it happening again in the future, before those types are released under a finos/fdc3 namespace. Do you concur? I suspect having you on the team to help us with reviews might help catch similar things (that matter more in .NET than JS/TS) will help! @bingenito would implementing this in .NET be a case of changing the public interface IIntentResolution
{
...
Task<IIntentResult?> GetResult();
}i.e. adding the That said I do hear there are newer approaches in later c# language versions (and I'm nowhere near competent in the old ones, let alone new ;-) ) |
|
/easycla |
resolves #1107
Updates FDC3 2.0's docs to match the correction applied in 2.1 and adds a minor clarification in the 2.1 and next specs to carry over into future versions.
An additional branch and PR will be needed to correct the type in a 2.0 NPM module release - although most will move to the 2.1 module (which has the correction and is backwards compatible with 2.0). We can do that release to NPM after this change is merged and approved.